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(manuscript received 22 Apr 86, after correction 6 Feb 87) pp 27-32 


[Article by V, P, Zhabeyev] 
[Text] Formulation of Problem 


Software has been reclassified as a product of industrial significance. Thus, 
the classes and groups of the industry-wide system of standards that previously 
dealt with the development, production and use of hardware has now been ex- 
tended to include inventoried software, i.e., programs on data medium that 

are the product of commercial production (GOST [All-Union State Standard] 
19.004-80). Of most relevance are the 4th class of standards--product quality 
indices, the 15th--development and organization of production, and the 27th-- 
the "Reliability in Engineering” standards. 


While acknowledging the fund mental differences that exist bewteen methods 
of producing, controlling, testing and using hardware versus software, we 
will adopt the following thesis: The quality must be based on the indices 
for both hardware and software system existing, thoroughly-tested system 
for controlling the quality and testing of products, with its unififed 
methodological and methodology and standards [1]. 


A representative (italicized by the author here and below) structure of 
measurable quality indices for the reliability of inventoried software is 
laid out in this article. This structure provides a single value for the 
reliability of inventoried software, while taking maximum advantage of the 
existing system of technical documentation standards. The principal require- 
ments of facilities for the automated measuring of quality indices for in- 
ventoried software are also specified in this article. 


Basis for Set of Axioms Used 


A general definition of the concept "reliability" is given in GOST 27.002-83, 
"Reliability in Engineering. Terms and Definitions," and as it relates to 


automated process control systems, in GOST 24.701-83, "ASUTPs. Reliability. 
Basic Assumptions." 








The following axioms are fundamental to these standards: 


Al--a product can be in either serviceable or non-serviceable condition. 
Although the term “serviceability” is introduced in GOST 27,002-83, in this 
paper it is regarded in accordance with [2] as a broader property than 
reliability. 


A2--a product maintains the values of all its parameters over time and with‘ 
set limits, 


The following components of reliability are a logical extension of axioms 
Al and A2: failure-free performance (B), longevity (D), maintainability (R) 
and consistency (S). In turn, the nature of each component is based on one 
or more components oi the next level of the hierarchy. 


Failure-free performance: 
Bl--serviceable condition is maintained for a certain period of time, 


B2--serviceable condition is maintained for a certain accrued operating 
time, 


Longevity: 


Dl--the product is considered serviceable until the onset of critical 
condition, i.e., the condition beyond which further use is impermissible or 
inadvisable (GOST 27,002-83), For example, technical and economic factors, 
the consequences of failures and critical condition, etc., can be used as 
indications of failures and critical condition in inventoried software 
(GOST 27.103-83, "Reliability in Engineering. Criteria for Failures and 
Critical Condition, Basic Assumptions"), 


Maintainability: 

Rl--the product must be adapted for the prevention and detection of the 
causes of failure and defects and for the maintenance and restoration of 
serviceable condition. 


Consistency 


Sl--the product maintains the values of its indices for failure-free per- 
formance, longevity and maintainability both during and after storage, 


$2--the product maintains the values of its indices for failure-free per- 
formance, longevity and maintainability both during and after transport. 


The validity of these axioms for defining the software quality indices is a 
subject of fundamental dispute. The following specific features of software 
are advanced in [3-6] as the main arguments against using the existing 
system of technical documentation standards, or at least its principal 
documents, 














Hardware failures result from physical defects in individual components, 
the influence of the environment, operating conditions, etc. For software, 
failures are due to algorithm and program errors, the number and cost 
(consquences) of which are determined to a considerable degree by the sub- 


jectively chosen development technology. 


Hardware, unlike software, is subject to physical wear and aging. 


It is impossible to increase the value of a software quality index by re- 
placing one component with another copted from the same original, since one 
of the conditions of copying is that the copy must Be tdentical to the 


original, 


A specific defect can be eliminated by replacement of the defective component 
with a component that is based on another algorithm or development method; 
but the possibility of introducing new algorithm and program errors in the 


process cannot be discounted, 


Other characteristics of software that both support and refute the arguments 
advanced in [3-6] can be pointed out, In the author's opinion, this situation 
has resulted from attempts to use a single set of quality indices for all 
stages of the software life cycle, The irrattonality of this approach is 


pointed out in [3]. 


Having discussed the main points of view concerning the reliability of 
software, and synthesizing the positive results obtatned in [3-6], let us 
proceed to the selection and substantiation of each component of software 
reliability, while limiting ourselves to one stage of its life cycle: 


"Funding, Reproduction, and Support,” 
Reliability Models for Inventoried Software 


For hardware, the concepts "time" (A2, B1) and "accrued operating time" (B2) 
are used in the most obvious, concrete sense and are essentially analogous, 
since accrued operating time can be examined only over a certain time period, 
But if a program is run repeatedly with the same input data (the determinate 
variant), then the same errors either will or will not occur repeatedly in 
the process, since there are no destabilizing factors (wear and physical 
aging) for software. Its serviceability will be checked for one point, L, 

or for a region, M, (fig la) defined by the set of inputs 


Z{(M]) =F [A], (Y}); (1) 

AX, SIX) X,. Mi SIYIS Ys, 
where [+] indicates that the corresponding value of factors X and Y is a 
discrete quantity belonging to the set [Xy 2, Y1 2]. 


If the values of the factors and the limits of the constraints in (1) are 
selected randomly, then it becomes possible to cover region M with discrete 














points whose density is determined by the characteristics of the rule for 
selection of input sets and algorithms for processing them, i.e., by the 
testing strategy used, 


The serviceability of software can be tested only for discrete points of 
region Z by means of a sequence of procedures of this kind (determinate 
and/or random), since testing the paths of all logical routes is practical 
only for relatively simple software, such as programs for input/output, 
interchange, transmission, and calculation of technical and economic indices. 
Testing all routes for more complicated software (application packages and 
libraries, compilers, operating systems and versions of them, etc.) is often 
infeasible from a practical and/or theoretical (algorithmic) standpoint. 
According to Nelson's model [7], whose argument is the number of program runs, 
only an estimate of reliability can be obtained in these cases; 


n 
Rin) = &XP py In (1 — Pm)), (2) 


where P,, is the probability of failure when executing the m-th run of the 

program and R(,) is the probability of failure-free execution of n runs of 
the program. In addition, this estimate is reliable only when each run is 
executed with a new input set, (1). 


Let us assume that in the process of testing, the software's serviceability 
was not tested in local region M, (fig la), and that the input sets, 

[X, 4» %3 4), which define this region, do in fact result in failure 
sitiations and/or failures if Ty (a parameter of the tested software's 
reaction) exceeds a specific level--the "protective failure" level [4] 

(fig 1b). 


Any values of the most important factors (for the specific application con- 
ditions) can be chosen as the boundary distinguishing failure situations 
from failures: the expenditure of physical, technical and/or time resources 
necessary for eliminating the consequences of a failure or failure situation, 
the probability of restoration of serviceable condition, the efficiency pre- 
servation factor, etc, The boundary between a software error and failure 
can be drawn similarly, 


Another (time) representation of region Z is presented in fig lb, from which 
it follows that failure situations corresponding to input sets (1) can 
originate only in intervals At ;, Atg and At3, and failures at moments in 
time A), Az, B1-B3 and Cy, In this interpretation of the relationships 
between the factor (cf. fig la) and time (cf. fig 1b) representations of 
regions of action of input sets, the characteristics of the stream of 
software errors (failure rate, mean time between failures, operating time 

to failure, etc.) take on the meaning of a function of time, i.e., one that 
is analogous to the characteristics of the stream of hardware errors. 
































eom- ofan 












y 
4 ! 
' 
Yy eet Nk - - - - == 
i] a t 
I, eat, - 4t, i a ae At, 
, a ' ; yy 
1 | Bat 
' ‘ ‘ j 
ax “ip fat i) | Serene 
| it iti : 
0 rt b) —S C 











Figure 1. Forms of Representation of Signals: a--factor; b--time 


As an illustration, the number of errors of a certain kind of software, PS,;, 
used by various users, P, and Po» is presented as a function of time in 

fig 2, The streams of errors n’, nj, n,(Z) =n, + nj, of the software PS 
that is in use have different characteristics for each case: t, and t!! 
represent the time of the beginning of its use (delivery), ny 4) is the 
number of errors, where j = 1, 2, and ty, ti» +++, t3 and tie ti» sees 03 
are the moments of appearance of errors. 


Thus, for software, too, the stream of errors is determined by how it is used 
and the conditions under which it is applied and serviced. Under conditions 
of servicing we include the possibility that additional errors will be intro- 
duced in the process of eliminating old ones, 


Taking into account these distinctive features of the software and the results 
obtained in [8], the function for the number of errors in the software PS, 
that is being used by a specific user has the following form: 


E; (Tl; (t)] = Et + aQ, (1 — 1"), (3) 











where I',, is the initial (for a specific t,) number of errors, Q, is the 
rate of introduction of new errors, k is the error rate, and a 2. the degree 
of the influence ("weight") of the errors introduced, where 0 < a < l. 
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Figure 2. Number of Errors Revealed by Users, Py and Po» 
in Process of Using PS; 


Relationship (3) adequately demonstrates one distinctive feature of inventoried 
software--the dependence of the stream of errors on conditions of operation, 
application and servicing. However, in the course of its application by the 
consumer, the use of relationship (3) encounters a number of difficulties 
(sometimes of a fundamental nature): It is necessary to (determine) the 
initial number of errors, the rate of introduction of new errors, the "weight" 
(consequence) of each error and the error rate. Thus, an exnression that 

is analogous to Bernoulli's theorem and is discussed in [11] is more appro- 
priate for solving the problems formulated in this paper: 


ni!) 
RQ, (1) =1— 4 
Cpe te, (4) 





where Ry Cy) is the probability of failure-free operation of PS; for specific 
user P,, N is the number of startups of PS;, and nfJ) is the number of 
successfully completed startups. 


By virtue of the simplicity of gathering and obtaining this kind of data and 
the obviousness of relationship (4), it is easy enough for the software 
supplier to make use of. However, he must take into account the following 
features of relationship (4), which was determined by the specific software 
he is using, his testing strategy and the operating conditions. Failures, 
errors and failure situations represent a complete group of events only in 
the case when the input sets uniformly cover region Z, i.e., when PS; is 
used in all modes and under all application and servicing conditions 
regulated by the relevant technical documentation standards, 





An analysis of relationships (2) to (4), as well as the results obtained 
in [1, 3 and 7-10), makes it possible to assert the following: 


The reliability of inventoried software does not by its nature depend on time, 
but in the actual use of the software, it appears as a function of time, 


The representation of the reliability of inventoried software as a function 
of time is used as a convenient physical interpretation based on the obvious 
factor that the error stream of software that is in use ts a function of 
time, operating modes and conditions of application and servicing, 


A statement concerning an improvement in the reliability of the software in 
use is valid only if, in the elimination of errors detected or in the improve- 
ment of individual quality indices, new errors are not introduced ox theor 
influence is small enough to be disregarded (q = 0), and if the following 
condition is fulfilled: The "weight" of the next error detected is smaller 
than that of the preceding one. 


The number of errors detected is reduced, as a rule, and the reliability of the 
software in use is increased with an increase in the number of users, which is 
equivalent to an increase in the intensiveness of use of the software, and the 
coordinated exchange of information among the users. 


Conclusion 


In spite of the differences in the nature of hardware, versus software, failures 
(errors), the following conclusions can be drawn. 


Axioms Al, A2, Bl, B2 and Rl are applicable for inventoried software as a 
PTN [not furthered identified] product, since the reliability of inventoried 
software can be represented as a function of time, modes and conditions of 
application, servicing and repair. 


The possibility of introducing significant new errors logically implies the 
applicability to software, too, of Al and of the concept of critical condi- 
tion (Dl), since according to GOST 27.103-83 the appearance of processes that 
hinder the functioning of the equipment is also an indication of failure and 
critical condition, in addition to the indications pointed out earlier. 


The idea of software as a program product, i.e., a program on data medium 

that is the product of commercial production (GOST 19.004-80), the expansion 
of the delivery area and the more extensive use by consumer of computer media 
all increase the probability of damage to the media during use, storage and 
transport. The service life of standard media is thus shortened, This 
situation calls for observation by the supplier of the axioms defining quality 
in storage (Sl) and transport (S2). 


The lack of a time relationship between working and conflict input sets 
makes it possible to organize accelerated tests of inventoried software. 














Taking the above into account, as well as [1] and GOST 27.002-83, let us 

formulate a definition of the reliability of inventoried software: 

Preservation of the values of quality indices for the reliability of . 
inventoried software can be guaranteed for an unlimited time of use and/or 

accrued operating time if the modes and conditions of application, servicing, 

repair, storage and transport meet fully the conditions and constraints speci- 

fied by the technical documentation (service log, testing program and procedure, 

and specifications). 


This definition is sufficiently constructive for the listed problems, in that 
it clarifies the relationships between the developer, supplier, and user. 
Furthermore, it does not remov. responsibility from the supplier, as might 
appear at first glance, since according to the standards in force (OST [All- 
Union Standard] 26 1121-83, "Development and Set-up of Software for Production 
in the Instrument Making Industry," and OST 25 780-84, "Software. Procedure 
and Rules for Making Tests") the supplier is obliged to participate in all 
kinds of tests on the software, beginning with the conceptual and/or technical 
designs. 


On the other hand this definition of the reliability of software imposes a 
number of completeness (thoroughness) requirements on the testing. According 
to GOST 20911-75, "Technical Diagnosis, Principal Terms and Definitions," 
verification tests and/or tests for finding defects, procedures for choosing 
tests inputs [11-13], and a procedure for supplying them to the input of the 
software being examined are required [14-16]. 


The approaches discussed in detail in [14-16] make it possible when developing 
an inventory of software to implement both determinate and stochastic testing. 
Stochastic testing deserves particular attention, for it is the most effective 
when supplying nontrivial software--application packages, in particular. 


In conclusion it is necessary to point out the existence among users of 
fairly widespread, but up to now insufficient!y formalized, qualitative 
methods of determining the values of indices for software reliability by 
means of fuzzy relationships [17, 18]. Under this approach isolated, compre- 
hensive, or integrated quality indices are determined by means of one of two 
equivalent scales: the linguistic (<excellent>, <very good>, <good>, <satis- 
factory>, <poor>, <very poor>), or numerical (point)--from 1 to 7 (10) 
points. In principle other quality scales could also be used. 


In spite of the subjectivity factor and the "roughness" of approximation 
(the use of a scale not higher than an interval scale is permitted), the 
method of fuzzy relationships makes it possible to obtain sufficiently 
representative estimates [18, 19], particularly at the initial stages in 
the development of software and with limited data, e.g., if the software 

is used for an insignificant calendar period or the number oi users is 
limited. It should also be mentioned that the method of fuzzy relationships 
in no way contradicts, and is even based on, expert rating methods regulated 
by a group of GOSTs (23554.0-79, 23554.1-79, 23554.2-81). These state 
standards are the basic ones for the organization and performance of the 
expert rating of software before it is added to the available inventory. 
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SOFTWARE 
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"Iset" Information Reporting System 


18630234b Kiev UPRAVLYAYUSHCHIYE SISTEMY I MASHINY in Russian No l, 
Jan-Feb 88 (manuscript received 27 Mar 86, after correction 18 Dec 86) 
pp 107-109 


[Article by V. G. Loginov, V. V. Pleshchev and V. V. Protasevich] 


[Text] The Iset information reporting system was developed at the main 
collective-use computer center of the Sverdlovsk Oblast executive committee 
to meet the interactive information needs of users at various levels. 


Level 1. These users are chairmen of executive committees and their 
deputies, chiefs of departments and administrations, and directors and 

their deputies. These people as a rule work with information that has al- 
ready been organized into a report. The layout of these reports is quite 
varied, they contain integrated information concerning multiple plans, their 
retrieval time is minimal, and the interactions required to retrieve and 
review vhem must be as simple as possible. The reports for these users are 
prepared at the following levels. 


Level 2. These users are functional specialists, not programmers, who have 
the background for generating reports. These users are capable of directly 
satisfying their own information needs and/or preparing information at the 
request of first-level users. 


Level 3. These users are applications programmers who develop software for 
first- and second-level users, The Iset system offers third-.evel users 
support in the development and completion of tasks. 


Level 4. These users are data processors who transfer the data to the Iset 
system for first- and second-level users. 


Level 5. These users are the administrators of the Iset system. Administrators 
are responsible for the content of the database, its integrity, and 
reliability; and they grant other categories of users access to the database. 
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Structure of Database 


The database consists of documents for first-level users (completed reports), 
documents for second-level users (blank forms), documents for third-level 
users, and catalogs. 


Completed reports are in the form of text or two-dimensional tables. Each 
report is characterized by the period of time over which it was formed and 
the date of storage. The date of storage is written in the text of the 
report. Completed reports are stored in data sets organized into a library 
or in sequential data sets with a record length of up to 128 bytes. If 
completed reports are stored in symbolic libraries, then each library con- 
tains documents of a single form and single kind of information. Each 
division of a library is made up of versions of a single document covering 
the various time period. 


Blank forms are intended for the entry of information and/or for making the 
calculations necessary for the completion of the report. 


Third-level user documents can be divisions of symbolic, object, or load 
libraries or data sets having any structure and organization, 


A catalog is a description of a set based on some criterion. The database 
contains a user catalog, a section catalog, a topic catalog, a report 
catalog, and a time-period catalog. 


User Catalog 


This is the highest-level catalog, and it contains the following information 
on each user: his code; the library name; section, topic, and report 
catalogs; the name of the volume in which the library is located; and, if 
necessary, the user's procedure for entering the system. Thus, user catalogs 
can be placed in multiple data sets, which prevents accidental damage to the 
catalogs and makes it possible to limit access to data. 


Section Catalog 


This is the first catalog level in the Iset system that is relevant to the 
individual user. The organization of the subdivisions is indicated to assist 
the user in locating data. The sections are numbered sequentially, and in- 
formation is given on the topics listed under each section, 


Topic Catalog 


This is the second catalog level in the Iset system; it is subordinate to the 
section catalog. Topics are numbered sequentially in this catalog. If a 
topic is itself a section, then such is indicated in the topic catalog, and 
another topic catalog is listed under this topic. There are no limits to 

the branching of this hierarchy. The topics are the concrete manifestation 
of the organization of the division. In the specific case, a topic catalog 
is a catalog of scenarios or a previously-selected sequence of documents. 
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Report Catalog 


This is the third catalog level that is relevant to users; it contains a 
listing of the specific reports available to the user on his chosen topic. 
Every topic that is not also a section or scenario contains a report catalog. 
The location of the report (volume, data set) and its formatting requirements 
(mode, width of margin, width of page, etc.) are all indicated in the report 
catalog. 


Time-Period Catalog 


If a report is stored in a library and it is tndicated that it covers a specific 
time period, then the next catalog level is the catalog of time periods (or 
library divisions). This catalog is formed at the time of output of the 

report. The periods are numbered according to their dates, beginning with 

the earliest and ending with the latest. The divisions are numbered 

according to the order in which they appear in,the library's index. 


In order to ensure security and to limit access to the data in all catalogs 
stored in the database (section, topic, scenario and report catalogs), the 
codes of those users who have access to a specific section (topic or report) 
and for whom access is forbidden can be listed. 


Structure of Software 


The Iset system was developed to satisfy the needs of users at various 
levels for interactive access to a database, to ensure the integrity of the 
database over time, and to develop and manage the database. The Iset system 
includes four tasks for attaining these goals, 


Iset-Input Task 


This task addresses the goal of developing and managing a database. A 
catalog of users is put together and libraries with catalogs for each user 
are distributed (there can be a single library for all users or each user 
can have his own library). For third-level users working on the development 
and running of tasks it is desirable to assign each functional task its own 
library for catalogs. 


Next, the range of questions about which the user will need information is 
formulated and a section catalog is constructed (e.g., industry section, 
territorial section). The range of topics on which information is to be 
offered is determined for each section (e.g., the topics under the 

industry section might be agriculture, urban transportation, coastruction, 
etc.). If a topic encompasses a wide range of questions, then it could be 
divided into subtopics (e.g., agriculture can be divided into animal 
husbandry, crop cultivation, etc.). If a topic is narrow, then it is 
divided into reports for which a report catalog is constructed (e.g., urban 
transportation can be divided into the following reports: entry of street- 
cars onto lines, entry of buses onto routes, etc.). 











The next step is to determine the data sets in which the texts of reports 
will be stored. If the information is periodic in nature (e.g., daily, 
weekly, monthly, etc.), then a symbolic library with the library's divisions 
coded according to the date the document was created is preferable. A 

unique system for coding time perfods was developed for this purpose. If 

the report stands alone and does not depend on the time of its creation, then 
it can be stored in a data set that is arranged sequentially. Documents for 
third-level users can be stored in data sets having any form of organization 
(sequentially indexed, directs etc.). These sets and the method of process- 
ing them are indicated in the report catalog. 


After the catalogs and data sets have been created, the method of loading 
each report is determined. The document can be created from a standardized 
report form, by means of the PRIMUS monitor [1], through batch processing 
and functional tasks, or from other reports through the Iset-Calculation 
facilities, 


If a (symbolic) document is to be processed by the Iset-Archive task, it 
must have one of the three following control statements in its first line: 


KHRANIT DO [STORE UNTIL] DD.MM.YY 
KOPIROVAT S [COPY AFTER] DD.MM.YY or 
UDALIT S [DELETE AFTER] DD.MM.YY 


where DD, MM, YY [Day, Month, Year] is the date when the document must be 
either copied into the archive (in the first case with its deletion from 
the set, and in the second without its deletion) or deleted without copying 
(the third case), Catalogs and documents can be corrected either by means 
of the PRIMUS monitor or by means of the Iset-Interaction task. 


Iset-Interaction Task 


This is the principal tesk in the Iset system; it implements collective 
access to the database for all categories of users who have been permitted 
access to the Iset system (whose codes are in the catalog of users). 


Entry into the task is attained by entering the "Iset" command on the 
screen of the PRIMUS monitor. If access to the Iset system is permitted, 
then the user conducts further work within the framework of the commands 
of this system. 


A so-called initial scenario or sequence of commands affording immediate 
passage to the required level (e.g., the required catalog or document to be 
reviewed) can be established for each user in the Iset system. 


All work in the Iset system is controllea through user commands. A listing 

of the section, topic, report, and time-period catalogs appears on the screen, 
from which the user can select the desired section, topic, report or time 
period by either its number or name. It is possible to obtain information 
about working in the [set system at each working level. Having listed the 
sequence of numbers for the report, section, topic, and time period, the user 
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can proceed to either the review or correction level for the document, 
depending on which working mode was selected for the report from the report 
catalog. The operating mode can be changed at the time of output of the 
time-period catalog--for all periods at once or for a specific period, Of 
the available modes the following are of interest: document review, document 
correction (from spot corrections to complete rewriting), job execution (if 
the document is a batch-processing job written according to the rules of the 
Unified Series operating system), renaming of time periods (or divisions), 
and deletion and addition of new time periods (or divisions), 


It is possible at any time to transfer to the PRIMUS monitor command mode 
(for third- and fourth-level users). 


The interactive control commands are very simple and do not require special 
training. The following are the principal commands used at any stage of 
interaction, 


N--Go to section catalog 

A--Go to scenario catalog (only if a scenario catalog exists 
for the specific user) 

T--Go to topic catalog 

S--Go to time-period catalog 

Ye--Return to preceding level 

K--End session 

?--Obtain instructions for working at the present stage 
of interaction. 


Commands for going to catalogs only work going up the hierarchy, i.e., it 
is possible to go from the report catalog to the section catalog report 
using the N command; but in moving down the hierarchy it is necessary to 
indicate the number (or name) of the desired section, topic or report. 


The scenario catalog contains the required sequence for accessing a 
document (or catalog). The required sequence is set into operation when 
the number of the scenario is indicated, Thus, the use of scenarios makes 
it possible to reduce to a minimum the sequence for finding a require. 
(often used) document. 


The Iset system provides the following functions for working at the document 
level: 


The scanning of an entire document from beginning to enc, page by page (by 
simply pressing the "Input" key). 


Proceeding to a specified page (by entering the page number), 
Going forward (back) a specified number of pages. 


Finding a required page by context (the line on which the text to be checked 
lies can be specified in order to shorten the search time), 


Correcting a page (by entering the I command). 
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Correcting a page in text blocks (the I'<tekst>'’ command). This command 
makes possible the standardized input of information in "windows," i.e., of 
preestablished divisions of a document for the entry of data. After one 
window is filled the cursor moves to another one, etc., until the entire 
screen is filled (all windows), or the contents of a window are not 

changed when the cursor arrives at it. Next, the data set is saved and 
"on-the-spot" updating continues. 


Copying a page as the next page in the data set (the D command). The page 
can be duplicated as many times as is necessary, but it must be kept in mind 
that duplication is performed only within the framework of the data set (on- 
the-spot updating). 


A single screen of readout is called a page. The number of lines on a page 
is indicated in the report catalog (no more than 22). In addition to the 
number of lines on a page, a document can have characteristics such as page 
headings (i.e., a group of lines that from the beginning of the document 
appear on every page), margin widths (if a document has a line length of 
more than 80 characters, then the right and left parts of the document can 
be viewed and data on the screen from the left half of the document can be 
saved), a position number for the second part of the document, etc. 


In scanning it is possible to view a document for the previous date (the P- 
command), the next date (P+), the last date entered (P9399), and the 

first (Pl or PO). If the document does not cover a time period, but is a 
division of a library, then the commands described above access the next, 
preceding and other divisions according to their position in the library 
index. 


Iset system administrators are afforded the capability of scanning the data- 
base by indicating the code of a specified user in the interaction process. 
They can thus keep track of the database's integrity and monitor the 
security system. A system administrator can also promptly intervene in the 
actions of other users, scan a specified user's screen buffer, and remove 
his Iset-Irteraction task if necessary. 


The gathering of statistics on a user's work at a terminal is provided for 
in the Iset-Conversation task. Each command by a user is recorded in a 
specially organized data set for gathering statistics which can be printed 
by the system administrator as necessary. The keeping of statistics makes 
it possible to keep track of users’ work and of access to the database. It 
is also possible to write scenarios for specific user groups on the basis of 


statistical data. 
Iset-Archive Task 


This task is used for keeping an archive of "obsolete" documents; and it 
performs the tasks of loading obsolete documents (with expired storage 
dates) into the archive (superfluous gaps are deleted in the process), 
dumping documents from the archive on request, and forming an archive 
inventory list. 
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The database's archives are managed user by user, which makes it possible 
to distribute the various user-level documents tn various archives. Third- 
level users can also manage archives by themselves, while management of the 
archives for first- and second-level users can be entrusted to the Iset 
system administrators. ! 


For programmer users the archive system makes it possible to keep old 
versions of their programs, data, etc, They can thus return at any time 
to an earlier operating version of a program. 


Iset-Calculation Task 


This task is designed for automating the performance of calculations on 
documents stored in the database (blank forms and completed reports). 


Blanks are prepared by the OFORT system [2]. A form consists of various 
groups of lines--some intended for input data and others for output. It is 
input by batch processing or interaction with the computer. Windows, i.e., 
places for the input of variable data, are included in these groups of 
lines, The windows are identified by labels that uniquely indicate their 
address. All calculietions are indicated on the form at the label level. 
The following operations are permissible: the calculation of percentages 
and other arithmetic operations, the transfer of numeric and symbolic d. “a, 
totaling, and decoding. 


Variable data can be entered in the windows from the Iset-Interaction task 
by means of the correction-by-context command or by filling in the form 
using functional tasks. 


A single form can be used for many different documents that have the same 
format, i.e., for which the location of the windows and the calculations 
are identical. 


A calculation command is required for each form. This command is a 

procedure describing in fairly simple language the sequence of operations 

for completing the form, i.e., what documents serve as input for calculations, 
to which groups of lines they apply, and under what name and location the 
output information is to be placed. If it is necessary to file the output 
report according to the Roman or Russian alphabet, then the sorting procedure 
is also indicated in the calculation command. 


Functional Characteristics of the Iset System 


Let us present some data on the Iset-Interaction task. Main memory capacity 
required is 8K + 6K x N (where N is the number of users working simultaneously) 
Reaction time is 0.5 to 1 s when going from level to level. If a report search 
scenario is initiated, then the reaction time is 2 to 3 s (for a YeS7927 

local display station and YeS1033 computer; the reaction time is two to 

three times longer for a remote display station). 
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SOFTWARE 


UDC 338:681.3 


Software Tools for the Generation of Reports Using the Language DLR and the 
PALMA DBMS 


18630235a Kiev UPRAVLYAYUSHCHIYE SISTEMY I MASHINY in Russian No l, Jan- 
Feb 1988 (manuscript received 11 Mar 86; after revision 18 Dec 86) pp 65-68 


[Article by V. G. Frolov] 


[Abstract] This article examines methods and software for the generation of 
reports using the high-level language DLR provided with PALMA, the first 
Soviet relational data base system. The major software facility provided 
is the RELPRINT program, which accesses a PALMA data base, performs page 
and line formatting of selected data and prints out a report based on 
parameters contained in a library of parameters written in the language 
DLA. These report parameters can be calculated manually or automatically 
generated by the NEATAB3 program. The RELPRINT program consists of the 
following modules: PROC RELPRINT (prints the report), QUERYGET (queries 
the data base), HEADRDR (places headers on the page), PARMGET (reads report 
parameters), PLMEXEC (reads one line), ANALYZE (analyzes the line), a line 
printing routine and PRINT-PAGE (prints the last page of the report). The 
individual modules of the RELPRINT program are briefly described. Due to 
its modular structure, the RELPRINT program can serve as a basis for the 
generation of a wide variety of reports in the PALMA DBMS. References 8: 
Russian, 


19 








UNC 621.382.82.001 
ARIS Circuit Modeling System 


18630235b Kiev UPRAVLYAYUSHCHIYE SISTEMY I MASHINY in Russian No 1, Jan- 
Feb 1988 (manuscript received 2 Jun 86; after revision 4 Nov 86) pp 94-96 


[Article by B. V. Batalov, S, G. Rusakov, V. P. Batagin, M. M. Zharov, 
A. A. Lyalinskiy, and S,. L. Ulyanov] 


[Abstract] The ARIS (acronym for automated design of integrated circuits) 
system models the electrical characteristics of LSI circuits based on 
bipolar and metal-dielectric-semiconductor devices. Various versions of 
ARIS run on the YeS and SM computers, the Elektronika-82 superminicomputer 
and the DVK-2M microcomputer. All versions share a common structural, 
linguistic, algorithmic and mathematical basis. This article discusses the 
capabilities of the software, including expansion of the system with addi- 
tional eleemtn models and types of analysis, hierarchical description of 
circuits provided by a fragmentation apparatus with no limits as to depth 
of embedding and number of fragments at each level, and generation of a 
metal-dielectric-semiconductor transistor list in the form of sublists of 
topologic and technological information. The structure and operating 
algorithms of the system and the functional capabilities of the various 
versions are described. The YeS computer version allows for a maximum of 
500 components, 250 nodes, 100 model parameter lists and 250 fragments. 

The memory requirement is 310 Kbytes. References 12: 8 Russian, 4 Western. 


UDC 681.3.06:621.3.049.774.3'14.001.2 
Data-Processing Software for Manufacture of VLSI Photographic Templates 


18630241 Moscow PRIBORY I SISTEMY UPRAVLENIYA ‘n Russian No 2, Feb 88, 
pp 14-15 


[Article by V. A. Lementuyev and V. Z. Popov, engineers] 


[Abstract] The machine description of VLSI topology produced by a CAD 
system is in the form of a set containing the geometric fields of each 
layer of the circuit. This article describes the TEMOS software package, 
which converts this machine-description of, VLSI topology to a description 
of the photographic templates required to manufacture the physical circuit. 
The components of the TEMOS package and their basic functions are: the 
PUROV program makes the transition from contour definition of topology to 
an ordered vector-level representation; the PUNION program implements the 
set-theory operations required to generate the individual layers; the 
PREOBR program makes the transition from vector format to the SOURCE or 
PPV format; the PSORT program performs global sorting of the topology file 
for a layer or the template description file; the PCOPY program performs 
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file transfer between the KULON-1 and RAFOS operating systems, The total 
length of the package is over 13,000 FORTRAN commands, Time required for 
performance of the individual operations in the TEMOS package and the length 
of the source and output files are presented for four topology fragments of 
varying complexity, indicating that the program package achieves a reduction 
in file length by approximately a factor of two. Figures 1, tables l, 
references 2: Russian, 
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APPLICATIONS 


UDC 658.512.011.56:622 
Mining Technology a CAD System for Open-Pit Mines 


18630236a Kiev UPRAVLYAYUSHCHIYE SISTEMY I MASHINY in Russian No 1, 
Jan-Feb 88 (manuscript received 3 Feb 87) pp 79-82 


[Article by V, A, Kovalenko and E. B. Sakimbayeva] 


[Abstract] The traditional method of manually calculating the parameter; for 
blasting operations at open-pit mines has a number of shortcomings: it is 
extremely labor intensive, it requires the calculation of correctional 

tables for the parameters of the explosive charges, and it inevitably involves 
errors in determining the geometry of the site and the coordinates of the 
bore holes. A significant improvement in the quality of blasting operations 
can be achieved by the use of modern planning systems and computers. A 
computer-aided design (CAD) system is suggested for automatic planning of 
drilling and blasting operations. The system consists of three major 
subsystems--mine surveying, blast planning and graphic output. The system 
operates with a data base including data from survey operations and 
geological studies at the mine. A flow chart and diagrams illustrate 
application of the system to planning of a typical open-pit mine blast. 
Figures 4, references 3: 2 Russian, 1 Western. 


UDC 681.3,513 

Determination of Contours in a Graphic Data File 

18630236b Kiev UPRAVLYAYUSHCHIYE SISTEMY I MASHINY in Russian No 1, 

Jan-Feb 88 (manuscript received 8 Jan 85; after revision 23 Jul 87) 

pp 88-89 

[Article by A. K, Gruzdev] 

[Abstract] For the purposes of this article, a graphic data file is assumed 
to consist of straight line segments, circles, and circular arcs. The article 


focuses on the task of determining the contours of all the fields into which 
a plane is divided. In the first stage, the file is divided up into elements 
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whose end points are the intersection points of the graph. In the second 
stage, any superfluous coinciding elements are eliminated. In the final 
stage, the actual contours are found by first replacing each element of the 
graph with two opposing directed line segments or arcs. A contour corresponds 
to one cycle in the oriented graph that results from this step. This method 
of determinig contours places no restrictions on the order of the elements 
wichin the graphic data file or their coordinates on the drawing. The method 
has been implemented in FORTRAN for the SM-4 computer as a part of a CAD 
system. Figures 2, references 3: Russian. 











NETWORKS 


UDC 681,324 


Comparative Assessment of Multifunctional and Special-Purpose Network 
Information Systems 


18630222a Riga AVTOMATIKA I VYCHISLITELNAYA TEKHNIKA in Russian No l, 
Jan-Feb 88 (manuscript received 18 Feb 87) pp 43-48 


[Article by E. V, Zinovyev] 


[Abstract] Present-day information systems can be classified as either 
multifunctional (general-purpose) or special-purpose, depending on their 
organization and the problems solved. General- and special-purpose features 
can now be combined in complex computer systems all functional levels, 
including operating systems, programming languages, application programs 
and hardware. The development of network information systems inyolves 
selecting the structure and make-up of software and hardware, It thus be- 
comes necessary to assess the efficiency of both multifunctional and 
special-purpose systems, 


An analysis is presented of the two kinds of organization of network 
information systems--special-purpose (computer system No 1) and mlti- 
functional (system No 2). Queuing theory and reliability theory are em- 
polyed to determine the maximum throughput and reliability of the two systems, 
The areas of application in which multifunctional systems are more efficient 
than special-purpose ones are determined. It is assumed that systems 1 and 

2 are equivalent with respect to hardware configuration and user requests 

and that they are comprised of an equal number of computers of the same type. 
But the internal organization of the two systems differs. Both systems offer 
the user access to the set R of various processes and resources. System 1 
consists of specialized single-function computers, each of which supports 
only one process or resource from st R. System 2, however, contains n multi- 
functional computers, each of which can support all processes and resources 
of set R. 


It is assumed that a multidimensional nonstationary Poisson input of user 
requests enters both systems and the rate of input of a given type of request 
is a known function of time. Maximum throughput serves as the efficiency 
criterion, Each computer is regarded as a service machine and the length of 
the request queue is unlimited. Both systems contain a control element 
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(dispatcher). It is demonstrated that system 2 is capable of more fully 
utilizing the throughput of its computers when request inputs are non- 
stationary. It is also shown that the efficiency of a computer system 

as measured by throughput and reliability, tends to increase as it passes 
from specialized to multifunctional organization, This gain is at the 
expense of further complication of the system's internal structure and 
process control algorithms, Generally, multifunctional systems provide a 
higher level of efficiency for computer systems, There are cases, however, 
in which special-purpose systems can be favored in view of the relative 
simplicity of their organization. Such a case occurs when the throughputs 
of systems 1 and 2 are equal--when inputs of various types are balanced, i.e., 
the rate of input is at a maximum for system 1 and is completely consistent 
with the computer's throughput capabilities, Figures 4; references 6: 
Russian, 


UDC 681,323 
Adaptive Memory Management 


18630222b Riga AVTOMATIKA I VYCHISLITELNAYA TEKHNIKA in Russian No l, 
Jan-Feb 88 (manuscript received 13 Jul 87 (17 Feb 87)) pp 49-56 


[Article by A, A. Prikhozhty] 


[Abstract] The problem of minimizing the exchange of information between 
various levels of memory in virtual page-oriented memory systems is dis- 
cussed, Response time is shortened and the computer system's throughput 
is increased when information exchange is reduced, The pages used around 
a certain time, t, comprise a "local set,” which varies over time. Memory 
management would be best if the pages from the local set that will be 
referenced in the future were in main memory. Since it is not possible to 
know the local set precisely, an estimate of it, Z(t), called the working 
set, is used in practice. 


The basic task of memory management is to estimate the working set in the 
process of running a program. Two types of memory management strategies 
are used to complete this task. The first assumes that the power of the 
working set varies over time and the other assumes that this power is 
constant. The most well known strategy, which is of the first type, is 
Denning's strategy, A number of modifications of Denning's strategy are also 
used, The most well known strategy of the second type is LRU, Denning's 
LRU, FIFO and MIN strategies are all summarized, It is demonstrated that 
Denning's strategy and other familiar strategies are particular cases of 
the adaptive strategies that are presented here. These adaptive strategies 
can be adjusted for specific programs and are capable of procedural changes 
in the middle of a run. The theory of adaptive memory management is pre- 
sented and the Ap and A, strategies are summarized, The Ap strategy is 
oriented toward programs with variable power of the local set; it minimizes 
the amount of main memory occupied and keeps constant the probability of 
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referral to external memory by varying when necessary the number of pages 
in main memory, The A, strategy is oriented toward programs with constant 
power of the local set; it places a fixed number of pages in main memory, 
The A, strategy is compared with the LRU, FIFO and MIN strategies. 


The results are given of a computing experiment that simulates the various 
strategies, The strategies were evaluated on the basis of the frequency 

of page exchange with external memory. The A, strategy made possible an 
exchange frequency 144 percent lower than that of the MIN strategy, 23 per- 
cent lower than that of the LRU strategy and 20 percent lower than that of 
the FIFO strategy. The Ap strategy worked on the whole better than the A, 
strategy and made possible an exchange frequency 9 percent lower than that 
of Denning's strategy. Adaptive strategies are not markedly worse than the 
familiar strategies in terms of complexity of implementation and speed and 
are therefore promising for practical utilization. Figures 2; 

references 11: 8 Russian, 3 Western. 


UDC 681,324 
Information-Computer Networks Based on Radio Communications 


18630232 Kiev UPRAVLYAYUSHCHIYE SISTEMY I MASHINY in Russian No l, 
Jan-Feb 88 (manuscript received 27 Apr 87) pp 37-43 


[Article by S, G, Bunin and A. M. Luchuk] 


[Abstract] Computer networks utilizing radio transmission rathern than 
cables have many advantages including great economy, high speed and ease 
of network development and modernization. Equations are presented for 
computation of the number of channels required and mean load on each fre- 
quency in a packet-switching computer network. The experience of the 
ALOHA network of the University of Hawaii is cited to demonstrate the 
advantages of a common relay over a central-computer to facilitate data 
interchange among numerous, sometimes mobile, users. The interaction of 
cells in a cellular radio network is discussed, Interaction of cells 
through sluices and geosynchronous satellites according to ISO protocols 
is noted as a possibility. Computer networks utilizing radio channels as 
their transmission medium have a number of unique properties that make them 
irreplaceable in networks with large numbers of often mobile users where 
costs must be controlled. Even local networks and computer systems can 
utilize radio channels and digital radio signals for high-speed data ex- 
change, thus making possible the creation of computing environments with 

a flexible architecture that is capable of changing during the performance 
of a task. Figures 9, references 12: 11 Russian, 1 Western, 
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